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ABSTRACT 



A network authentication system generates digital certifi- 
cates to users, which provide verification of the identity or 
other attributes of the users to conduct a transaction, access 
data or avail themselves of other resources. The user is 
presented with a hierarchy of queries based on wallet-type 
(basic identification) and non-wallet type (more private) 
information designed to ensure the identity of the user and 
prevent fraud, false negatives and other undesirable results. 
A preprocessing stage may be employed to ensure correct 
formatting of the input information and clean up routine 
mistakes (such as missing digits, typos, etc.) that might 
otherwise halt the transaction. The authenticator can be 
configured to require differing levels of input or award 
differing levels of privilege to the ultimate certificate. 
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When PostalSoft cannot assign (match) an address, it creates an 
error code that tells why the address could not be assigned. 



POSTAL SOFT ERROR CODE ACTION MATRIX 
(EXAMPLE) 




Action 


Error Code 


Attempt 1 


Attempt 2 


E101 


V 


M 


E212 


V 


M 


E213 


V 


M 


E214 


V 


M~" 


E216 


V 


P 


E302 


V 


P 


E412 


V 


P 


E413 


V 


P 


E420 


V 


P 


E421 


V 


P 


E422 


V 


P 


E423 


V 


P 


E425 


V 


P 


E427 


V 


P 


E428 


V 


P 


E429 


V 


P 


E430 


V 


P 


E431 


V 


P 


E500 


V 


P 


E501 


M 




E502 


V 


M 


E503 


V 


P 


E504 


V 


P 


E600 


V 


M 



T — 

156 



Action Code Definitions 

V Present this message: "Please verify that the address you have entered 
is correct and re-submit" 

■t .r^M "' Log transaction results and present this message: '''We'ar&tinSBIe'fo'^'" 
immediately authenticate your identity with the information you have 
provided. Someone from our Customer Support department will contact 
you within the next 24 hours. If you need to speak with someone 
immediately, please call Customer Support at 1-800-999-9999." 

P Log transaction results and proceed to Area Code Validation. 

FIG.10 
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Transaction Data Required for Transaction Logs [ — 



Transac 

Trans No. 


tionID 


Customer No. 




Consumer ID 




Date / Time 





Application information* 


Last Name 




First Name 




Middle Name or Initial 




buttix 




Maiden Name 




Current Address - Line 1 




Current Address - line ? 




Current Address - Cm »nty 




Current Address . CAty 




Current Address - State 




Current Address - 7ip Code 




At CA < 2 Years Indicator 




Former Address - Line 1 




Former Address - Line 2 




Former Address - Countv 




Former Address - Citv 




Former Address - State 




Former Address - ZiD Code 




Home Phone Number 




Home Phone > 4 Mos Old Indicator 




Area Code Chanae Indicator 




Home Phone Pub Indicator 




Work Phone Number 




Work Phone Extension 




Gender 




Date of Birth 




Social Security Number 




Drivers License Issued Indicator 




Drivers License Number 




Drivers License State of Issue 




DL Address * CA or FA Indicator 




DL-Address^'Line - ■* - — - 




DL Address - Line 2 




DL Address - Citv 




DL Address - State 




DL Address - Zip Code 




Application Information (continued) 



FIG.13 
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Mother's Maiden Name 




Year of Hiah School Graduation 




Number of Siblinas 




E-Mail Address 





* Information received on the application will be stored exactly as provided bv 
the consumer on the application form. 
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Processing Re 
Process ComDonent 


"suits 


Process Status Code 




Process Score 




Date / Time 





Valid Process Components 
SStM Validation 


Valid Process Scores 
Pass. Fail 


Address Validation 


RF 


Area Code Validation 


RF 


Drivers License Format Validation 


RF 


ACRO ID Compare 


Big, Regular Possible, No Hit 


MetroMail ID Compare 


B.RRN 


Drivers License ID Compare 


B,RR N 


Customer List ID Compare 


B.RR N 


Trade Line Test 


B,RRN 


Manual Evaluation 


B.RRN 


ID Decision 


B,R,R N 



Vain 

Status Code 
not assianed 


d Process Status Codes 
■~ - Description 
Process Comolete 


not assianed 


Process Comolete - Flaaaed for Manual 


not assianed 


Aborted - Cornm Error 


not assianed 


Aborted - System Error 


not assigned 


Aborted - Sent to Manual 



















SSN Vatic 


Nation Data 
Pass. Fail Not Invoked ^ 


SSN Issued Check 


RFN 


SSN Deceased 


REN 


SSN Fraud 


RFN 


Table Version Nofs) 





FIG.14 
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Postal Soft Output 


Outout Address 




Status or Error Code 




Record TvDe 




Directory Version 




Program Version 





ACROIDCo 
Files Returned 


mpare Data 
0.1.Z3.4 


Fraud Victim 


YN 


Safescan Code 




L90 Search Score 





ChoicePoint Drivers Ucens 

f^D 44 /-vf f^^r^rWri^te^e- Daft im/v^ 

or # ot uanaiaates Keturneo 
CP P151 Classification 


e ID Compare Data 
RS = Report Subject 


r^O Mama 1 oci 

i»r (Name - Lasi 




CP Name - First 








i ion its ouniA 




CP Date of Birth 




CP Gender 




CP SSN 




CP FSI - Name - Last 


Match, Discrepancy, blank 


CP FSI -Name -First 


M, DL blank 


CP FSI - Name - Middle 


M Q blank 


CP FSI - Name - Suffix 


M a blank 


CP FSI - Date of Birth 


M. D blank 


CP FSI - Gender 


M. D blank 


CP FSI - SSN 


M. D blank 


CP DL51 Classification 


CP = Current Personal 
CL = Current Learner's Permit 
CC = Current Commercial 
PP ~ Previous Personal 
PC = Previous Commercial 


CP Driver's License Number 




CP Driver's License State 




CP FSI Drivers License Nbr 


M, Q blank 


CP FSI - Driver's License State 


M. Q blank 


CP Driver's License Expiration 
Date 


oossible.future enhancement 


CP Driver's License Issue 
Date 


possible future enhancement 


CP AL51 Classification 


RA= Residence Address 
FA = Former Address 


CP Address - House Number 




ChoicePoint Drivers License ID Compare Data (cont) 



11i 



FIG. 1-5 
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CP Address - Sneet Name 




CP Address - Apartment 
Number 




CP Address - City 




CP Address -State 




CP Address -ZiD 




CP Address - ZiD Code + 4 




CP FSI- Address -House 
Number 


M, D, blank 


CP FSI - Address - Street 
Name 


M, D, blank 


CP FSI - Address - Apt Number 


M, D. blank 


CP FSI - Address - Citv 


M. D. blank 


CP FSI -Address -State 


M. D. blank 


CP FSI - Address - ZiD Code 


M. D. blank 


CP FSI - Address - Zip Code + 4 


M, D, blank 



* CP = Choicepoint 



MetroNet ID Compare 

MN Name 


Data 


MN Address 




MN Phone Number 




MN Primary Response Code 




MN Nm/Add Verification Response Code 




MN Phone Verification Response Code 




MN EDA Request 


XN 


MN EDA Request Confidence Code 


Null, if EDA Check = 'N' 



* MN = MetroNet 



Trade Line Test Dai 

Trade Tvoe 


ta 

WA.R&G 


Date Opened 




Lender Name 




Lender - Multiple Choice Options* 




Lender - Consumer Response 




Terms or Monthly Pmt 




TermsorMonthlv.Pn^ . 




Terms or Monthly Pmt - Consumer Resp 





* Multiple Choice Options should be stored in the order presented to the 
consumer and with the correct response included. 



FIG.16 
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Pattern Recognition Match Action 



Match Name 


Number of Sessions 
(returned from Pattern 
Recognition) 


Action 


Same Consumer 


0 


newOILT 


Same Consumer 


1 


previous QILT 


Same Consumer 


>1 


Suspected Fraud: lock out 


Same E-mail/Different 
Customer/Different Consumer 


0 


new QILT 


Same E-mail/Different 
Customer/Different Consumer 


Wr 


new QILT 


Same E-mail/Different 
Customer/Different Consumer 


>1 


Suspected Fraud: lock out 


Same E-mail/Same 
Customer/Different Consumer 


0 


new QILT 


Same E-mail/Same 
Customer/Different Consumer 


1 


new QILT 


Same E-mail/Same 
Customer/Different Consumer 


>1 


Suspected Fraud: lock out 


Same Last Name/Same IP 
Address 


0 


new QILT 


Same Last Name/Same IP 
Address 


1 


new QILT 


Same Last Name/Same IP 
Address 


>1 


Suspected Fraud: lock out 


Same Address/Same 
SSN/Drfferent Last Name 


0 


new QILT 


Same Address/Same 
SSN/Drfferent Last Name 


1 


new QILT 


Same Address/Same 
SSN/Drfferent Last Name 


>1 


Suspected Fraud: lock out 


bame Address/Different 
SSN/Same Last Name 


0 


new QILT 


Same Address/Different 
SSN/Same Last Name 


1 


new QILT 


Same Address/Different 
SSN/Same Last Name 


>1 


Suspected Fraud: lock out 


6for6 


0 


new QILT 


6for6 


1 


new QILT 


61or6 " 


->t ■ - 


Suspected Fraud: lock out 


Same Application 


0 


new QILT 


Same Application 


1 


new QILT 


Same Application 


>1 


Suspected Fraud: lock out 



FIG.19 
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TRADE LINE TEST POINT ASSIGNMENT MATRIX FOR TRADE TYPES (EXAMPLE) 


Max Allowable 
Certainty Score 


8 


8 


o 
o 


s 


8 


o 
o 


8 


8 


8 


8 


o 


8 


8 


o 


8 


o 

CO 


o 

CD 


o 

00 


O 
CD 


3 


O 

in 


o 


o 


8 


O 


Gas Card 
Question 






o 




o 


o 




O 


O 


O 








o 






O 




O 


O 










o 


Student Loan 




O 

CNJ 




a 




o 

CO 


8 




o 

CO 


o 

CO 






8 






8 




8 




8 








8 




Installment Loan 
Question(s) 








8 






to 

CO 






o 
in 










$ 






8 


8 








? 






; Auto Loan 
Question(s) 


in 

CM 


o 

CD 


o 












8 












in 


o 
in 


O 

in 












.'■Sil 






Mortgage Loan 
Question(s) 


o 
in 


O 

m 


o 

w 


o 

m 


o 
m 


o 

CO 










o 
m 


O 
UO 


8 


8 














o 
in 











o 

CM 

CD 
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CERTAINTY SCORES FOR ID DECISIONING - sorted by Certainty Score 


PROCESS RESULTS 


CERTAINTY SCORE 


ACRO 


MetroNet 


ChotcePoint 


Trade Line Test 


Standard 


Custom 


B 


R 


D 


b 


100 




LJ 


R 










R 

LJ 


P 

r\ 


R 


R 
b 


. .. 95 




R 


R 


p 


Q 


95 




R 

LJ 




D 

r 


Q 

o 


91 




R 


R 


KJ 


n 


90 




R 

LJ 


D 




Q 


90 




D 




K 


B 


90 




p 

r\ ... 




D 


B 


• 90 




Q 


H 




B 


86 




R 


R 
b 


r 


B 


96 




D 


D 
r\ 


M 

IN 


B 


85 




R 


D 

r 


B 


B 


85 




R 
IN 


R 


N 


B 


85 








R 


B 


85 




D 

r 


R 
b 


□ 

D 


B 


85 




D 

r\ 


K 


P 


B 


81 




b 


□ 
D 


B 


R 


80 




R 


D 

r 


R 


B 


80 




R 


Kl 


B 


B 


80 






•D 


N 


B 


80 




D 
rs 


D 
r 


B 


B 


80 




D 


b 


o 

R 


B 


90 




p 

r 




B 


B 


80 




D 
D 


P 

r 


P 


B 


75 




p 


b 


n 
P 


B 


75 




r 


b 


o 

K 


R 


75 




R 


p 


n 

LJ 


R 


75 




R 

LJ 


p 


N 


B 


75 




R 


M 

IN 




B 


7fi 




R 


R 

D 


b 


R 


75 




R 

r\ 


D 

r 


p 


□ 

o 


75 




R 


M 

_JN 


R 
b 




75 




P 


R 


M 


tJ 


75 


„ — 


P 


R 

•> 




D 


75 




R 


R 


p 
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Equifax identity Verificat ion Center 



Interactive Query 



To apply tor your digital certificate, you must enter the information requested below 
Required fields are BOLD. 



Personal Identification Information 

Your Name 

First I Paul ~ 



Middle [7T 
Last [ 



Benton 



suffix 

Gender O Female 
®Male 

Social Security Number |222-0l-4l4l| 



Date of Birth Montn 0 ay[£ZE] YearEHH 



Maiden Name r 
(if applicable) 1 



email Address | jsmltheabcdefg.com 



corSnatiw) 1 jsmitheabcdef ^ cam 



Current Address 

Address |3199 Barrack Drive" 



Line 2 [ 



City | AlpharettT 



State [GAig 
Zip 1 30202 | 



County/Parish I Fulton 



Time at Current I Less than 2 years I ▼! 
Address 1 1 1=1 



Former Address 

(Required if current address less than 2 years) 
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Address |8544 Fulton Industrial BlvcT 
Line 2 | 



City | Atlanta 



State | gaM 
Zip 130396 | 



County/Parish | Fulton 



Phone Number Information 

Phone Numbers may be formatted (nnn)nnn-nnnn , or nnn-nnn-nnnn , or n 
Home Phone Number |(77p) 592-36731 

Has the area code of your home phone | NO \*i 

number changed in the last 6 months? 1 UJ 

Have you had your current home phone |yesM 

number for more than 4 months? 1 

Is your home phone number published? fy^T] 

Work Phone Number ; — — [ 

Extension | | 

Oriver'sLicense Information 

Do you have or have you ever had a driver's license? o Yes 
(number and state required if yes) 0 No 

Driver's License Number | B36492014 — ] 



State of Issue |ga L»j 
Driver's License Address 0 Same as Current Address 
(Address required if different) O Same as Former Address 



Address £ 
Line 2 [ 
City [ 



O Different Address 



State 1 |rj 
a P i 



J 



Please enter the following information. 

It will be used for additional security 

FIG.32 

Mother's Maiden Name 

Year of High School Graduation (yyyy) 

Number of siblings (including hall and step siblings) 



FIG.33C 
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Equifax Identity Verification Center 



Interactive Query 



1 . Your credit file indicates you may have a mortgage loan, opened 
in or around August 1998. Please choose the credit provider for 
this account from the following options: 

O BANK OF AMERICA, FSB 
O DARBY BANK & TRUST CO. 
® HEALTH CARE CREDIT UNION 
O IBEW FEDERAL CREDIT UNION 
ONONE OF THE ABOVE 



2. Please choose the range within which your monthly payment 
falls for previously referenced account If you make bi-weekly 
payments, multiply that payment by 2.17 to calculate the monthly 
payment 

O $575 -$674 
0$675-$774 
® $775 -$874 
O $875 -$974 
ONONE OF THE ABOVE 



3. Your credit file indicates you may have an installment account 
(personal loans, electronic/appliance accounts, jeweler accounts, 
auto loans, etc.) opened in or around November 1994. Please 
choose the credit provider for this account from the following options: 

<§> EXCEL FEDERAL CREDIT UNION 
O HALLMARK FINANCE CO. 

-: v ^©INDEPENDENT BANK ■ - • — 

O JOE COOPER'S FINANCE CORP 
O NONE OF THE ABOVE 
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4. Please choose the range within which your monthly payments fall for 
previously referenced account If you make bi-weekly payments multiply 
that payment by 2.17 to calculate the monthly payment 

0$375-$424 
® $425 -$474 
O $475 -$524 
O $525 -$574 
ONONE OF THE ABOVE 



Submit Request 1 1 Cancel Request ] 



FIG.35 



Equifax identity Verification Center 



Interactive Query 



You have been successfully authenticated. 

To get your digital certificate, click the continue button. 



1 Continue 1 
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Equifax User Enrollment 



Enrollment Status 



The Challenge Response you entered does not match the one In our records Please 
re-type and click Check Enrollment Status agaia If the problem persists, contact the 
system administrator. 



To check the status of your user enrollment, please enter the Challenge 
Response exactly as you did when you submitted your enrollment request 

Check User Enrollment Status 



Challenge Question: What is Hash's favorite Hash ? 
Challenge Response: I shai 



I Check Enrollment Status 
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Equifax User Enrollment 

Submit Enrollment Request 



To enroll yourself and obtain a certificate to access Equifax's secure network: 



1 . Verify and submit the user enrollment form below 

2. Make sure you enter a Challenge Question of your choice (eg "What is 
the last 4 digits of your home phone number?") and the corresponding 
Challenge Response (eg "21457 When checking your enrollment status 
later, you must provide the same Challenge Response Unlike a typical 
password protection, the Challenge QuestiorVResponse combination is much 
easier to recall after a long period of time Since the Challenge Response b 
case-sensitive, you may want to use all lower-case or all upper-case letters. 

3. Follow instructions to bookmark the screen that allows you to check your 
enrollment status later 

4. On the Check Status screen, enter your Challenge Response to check the 
status of your enrollment request 

5. If your request is approved, your certificate will be downloaded 
automatically 

6. Follow instructions to confirm your certificate. 



Direct User Enrollment 

First Name: Paul 
Last Name: Benton 
E-mail Address: pbentoo @mycompanyxom 
Challenge Question: |what is Hash's favorite Hash } 

Challenge Response: Ishai 

I Verify and Submit I 



Exit and Re-authenticate 
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Equifax 

Certificate Central 

Certificate Central is the starting point for actual certificate issuance 

If you have any questions on Certificate Enrollment, please read the Equifax Certificate 
Enrollment Frequently Asked Questions and Answers for further information. 

What browsers are supported for certificate enrollment? 

Certificate enrollment supports Netscape Navigator 3.x, Navigator and 
Communicator 4.x, and Microsoft Internet Explorer 4.x with JavaScript enabled. 

Equifax Certificate Enrollment 

Mr. Benton, to request your certificate based on your successsful authentication, 
press the GO button 
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SYSTEM AND METHOD FOR SUMMARY OF THE INVENTION 

AUTHENTICATION OF NETWORK USERS r , . ft . . # . 

a KTn icciTrwr- a r\ir- rr\ i r-iriyriirTr- *tc ^ iiS an object of the invention to overcome these and other 

AND ISSUING A DIGITAL CERTIFICATE . . , c - j- •„ , ^ c t « . 

drawbacks or existing digital certificate systems and meth- 

CROSS-REFERENCE TO RELATED 5 ods - 

APPLICATION It is another object of the invention to provide a digital 

™_. , . - ... . . , certificate issuing system and method that perform a first 

This subject matter of this application is rdatcd to the authentication st based on , ^ , ofusc[ identification 

subject matter of U.S. application Ser. No. 09/315,128, ; „ f „,-„„ , f . „ ,, A . . . 

entitled "SYSTEM AND METHOD FOR AUTHENTICA- S^TfjS". ™* result determine whether to 

TON OF NETWORK USERS", filed May 20, 1999, and 10 5^1^^ authentication step using 

U.S. application Ser. No. 09/315,130, entitled "SYSTEM , " ' , . 

AND METHOD FOR AUTHENTICATION OF NET- Another object of the invention is to provide a digital 

WORK USERS WITH PREPROCESSING", filed May 20, certificate issuing system and method that perform a first 

1999, each having the same inventors and assigned to the authentication step based on a first type of user identification 

same assignee as this application. This application is also a 15 mformatlo ° a ° d > based on the results of the first authenti- 

continuation of a provisional application No. 60/086,256 cation step, determine whether to proceed to at least a 

filed May 21 1998 second authentication step depending on available informa- 

-r ~ * ' tion and the level of certainty ..oT authentication desired. 

FIELD OF THE INVENTION Another object of the invention is to provide a digital 

The invention relates to electronic communications, and 20 certificate issuing system and method with a multilevel 

more particularly to issuing digital certificates including authentication process, where a first step includes the pre- 

those for authenticating the identity of network users. processing of user-supphed information. 

It is still another object of the invention to provide a 

BACKGROUND OF THE INVENTION digital certificate issuing system and method which deter- 

The issuing of digital certificates to promote electronic * wntentw privilege level of a digital certificate to 

commerce is known. Digital certificates, that is, specially be . T "«*«»«*. for example, the financial and access 

issued files containing identification and other information, P n ^ e 8f or other classifications associated with the digital 
provide a level of security and authentication that gives 

vendors, suppliers and others comfort as they increasingly 30 In aD illustrative embodiment of the invention, a user who 

commit to electronic commerce. Digital certificates provide wishes to apply for an online transaction accesses a client/ 

electronic confirmation of the identity of a potential cus- server network through a client terminal. The server side of 

tomer or other user seeking to access a resource or to process me network includes an application server communicating 

a transaction. Digital certificates also regulate the access to wilh an authentication server. When the user wishes to 

particular transactions or information. For example, digital 35 mitiate me transaction or at other times, the authentication 

certificates can differentiate classes of transaction within a server determines whether the user's identity can be 

Web site based upon credit or other information contained in confirmed, and the level of authentication that may be 

a digital certificate or directory accorded to the user's identity based on specific to the 

Typically, the steps involved in deciding whether to issue vendor ^ transaction rules. 

» a digital certificate involve an interaction between a user 40 ^ transaction the user is applying for, such as an 

who wants to perform a transaction and a certification electronic brokerage trade, is either carried out or not carried 

authority. In most cases, the certification authority is not a out or ? me . r action taken depending on the results of the 

party to the eventual transaction but serves instead to qualify authentication. The extent of authentication processing per- 

the user to perform transactions by issuing a digital certifi- formed depends upon the nature of the transaction and 

cate. The certification authority queries the user for infor- 45 vendor "Specific requirements. Once the authentication pro- 

mation and attempts to match the responses to known data cess has ^en satisfied, the invention may generate a digital 

from databases to determine whether to issue the digital certificate recording authentication levels and other infor- 

certificate to the requesting user. In addition, the responses mation re l ated t0 the user ^ di S ital certificate can then be 

provided and the data available in the databases may be used presented in future transactions to avoid the need to reau- 

by the certification authority to determine the content or 50 meat icate the user for each new transaction event, 

privilege level of the digital certificate. That is, the certifi- For example, in the context of electronic commerce, 

cation authority determines what financial, privilege or other lower risk transactions such as relatively small purchases 

limitations will be associated with the digital certificate, as mav QOt require an extensive authentication process. On the 

indicated by the criteria of the online vendor. omer hand, more sensitive or greater risk transactions such 

An important aspect of the process of issuing the digital '55 ^ lar S e purchases or sensitive data access may 1 require a 

certificate is confirming the identity of network users. Van- more thorough authentication process and a greater level of 

ous systems exist that perform some level of user authenti- certainty. A greater level of security could conceivably be 

cation. These systems generally require a user to provide attained by automatically performing a thorough authenti- 

certain basic identification information, such as name, date nation process for every transaction. However, this approach 

of birth, social security number, address, telephone number 60 ^ CXirs unnecessary costs or resources in cases where only a 

and sometimes driver's license information. This type of l° wer l evei of certainty is needed. 

information is sometimes known as wallet information, and The invention avoids this drawback by enabling different 

it is compared to known data, such as from a credit file to levels of authentication to be performed based on the level 

determine a level of match between the stored and presented of security desired, reducing costs and unnecessary use of 

information. However this type of validation by itself is 65 system resources. 

limited and not flexible in accepting other types of back- Generally in the invention, the user is authenticated 

ground information. Other problems exist. according to their ability to respond to successive queries for 
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personal information and the level of match attained from 
comparing the information they provide with reliable data 
sources. The user is initially requested to provide a first type 
of identification information. The first type of information is 
preferably wallet-type information, that is, information such 
as name, address, driver's license or other information that 
may be commonly carried on the person. This information is 
transmitted to the authentication server which carries out a 
first level authentication process on that information. 

That first level authentication process compares the 
degree of match between the user-supplied first type of 
information and known data about the user from other 
sources. At the completion of this first level authentication 
process, the authentication server may allow the requested 
access, allow the requested access with restriction, refuse 
access or proceed to another level of authentication. 

Preferably, the second and any additional levels of authen- 
tication request a v second; *n'6n-wallet type of information 
from the user. The second type of information is preferably 
based on comparatively private information that only the 
user would know. For example, the second type of infor- 
mation may include mortgage loan or other information 
obtained from a credit report or another source. Such infor- 
mation is typically not carried with a person, and therefore 
the chances of fraud by someone who obtains lost or stolen 
information and attempts to execute a transaction are 
reduced. 

The private financial or other data elicited in the second 
level authentication process may be requested using an 
interactive query. The interactive query may include mul- 
tiple choice questions that are automatically generated based 
upon the information available in the known data sources. 
For example, the authentication server may access a credit 
file to identify loans of the user which are still in payback 
status. One or more loans may be selected and the lender's 
name and corresponding monthly payment amount retrieved 
from the credit file. 

The interactive query might ask the user for the lender's 
name or payment amount on the identified loan and offer a 
number of choices for each of the lender's name and the 
correct payment amount, only one of which is correct. 
Depending upon the responses, the user's identity may be 
authenticated fully, or to a greater or lower degree of 
certainty compared with that based solely on the first level 
authentication process. 

The invention may include a preprocessing stage executed 
before first or second level authentication. The preprocess- 
ing stage filters or corrects relatively minor mistakes in 
formatting and consistency in the user's responses, preserv- 
ing the transaction for further processing and avoiding 
needless termination before the upper stages are reached. 

BRIEF DESCRIPTION OF THE DRAWING 

.. FIG. 1 is -a flowchart* of- an- overall process for authenti- 
cating users according to the invention. 

FIG. 2 is a flowchart of an overall processing flow for 
authenticating users according to the invention in another 
aspect. 

FIG. 3 is a flowchart of certain aspects of second level 
authentication according to the invention. 

FIG. 4 is a flowchart of a preprocessing process according 
to the invention. 

FIG. 5 is a flowchart depicting a format verification 
process according to the invention. 

FIG. 6 is a flowchart depicting a standardization process 
according to the invention. 
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FIG. 7 is a flowchart depicting a validity verification 
process according to the invention. 

FIG. 8 is a flowchart depicting a consistency verification 
process according to the invention. 
5 FIG. 9 illustrates an example of a verification matrix used 
in the invention. 

FIG. 10 illustrates an example of error codes that may be 
generated according to the invention. 

10 FIG. 11 illustrates an example of a preprocessing matrix 
used in the invention. 

FIG. 12 illustrates a block diagram of an overall system 
according to the invention. 

FIGS. 13-16 illustrate a transaction record generated 
15 according to the invention. 

FIGS. 17 and 18 illustrate pattern recognition criteria used 
by the invention to detect irregularities, 

FIG. 19 illustrates potential action taken by the invention 
20 upon detection of pattern recognition criteria. 

FIG. 20 illustrates a scoring matrix for different types of 
accounts in second level authentication according to the 
invention. 

FIG. 21 illustrates a relative weighting of different types 
25 of queries used in second level authentication according to 
the invention. 

FIG. 22 illustrates a tiering of certainty scores into a set 
of categories according to the invention. 

FIGS. 23-28 illustrate an assignment of overall certainty 
scores from first and second level authentication results 
generated according to the invention, from highest to lowest. 

FIG. 29 illustrates a tiering of authentication results for 
different types of source accounts according to the invention. 
35 FIG. 30 illustrates action thresholds for a set of different 
actions according to the invention. 

FIGS. 31-33 illustrate preprocessing and first level 
authentication queries in an example authentication session 
according to the invention. 
40 FIGS. 34-36 illustrate second level authentication queries 
in an example authentication session according to the inven- 
tion. 

FIGS. 37-40 illustrate queries used to issue a digital 
certificate according to the invention. 
45 FIG. 41 illustrates a digital certificate generated according 
to the invention. 

FIG. 42 illustrates a remote authentication system accord- 
ing to the invention in which authentication is performed in 
an offline fashion. 

50 

FIG. 43 illustrates the offline remote authentication 
embodiment of the invention operating when a social secu- 
rity number data field is supplied. 

FIG. 44 illustrates the offline remote authentication 
55^ embodiment of the* invention operating when a ,l s6cial > secu- 
rity field is not supplied. 

FIG. 45 illustrates a block diagram of an overall system 
according to the invention, in another aspect. 

60 DETAILED DESCRIPTION OF PREFERRED 

EMBODIMENTS 

The invention in general operates in a network environ- 
ment and provides a system and method to authenticate a 
network user's identity using a hierarchy of information 
65 queries. The invention may draw on information from one or 
more data sources to execute the hierarchy of authentication 
stages, depending upon the transaction or data sensitivity. 
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The invention may dynamically adjust the extent of authen- through client 110. Authentication process 10 invokes the 

tication necessary, based upon preset thresholds or upon preprocessing step 26, in which the user is prompted to 

tests of input validity as the user supplies that information. supply a first type of user identification information. The 

A front-end preprocessing stage may serve to filter or first type of user identification information preferably corn- 
correct erroneous information such as mistaken zip codes, 5 prises wallet-type information such as name, address, phone 
missing digits or other matters of form so that the transaction number, social security number, driver's license number and 
may be preserved without needless termination before first other common personal information, 
or second level authentication. At the conclusion of the This information is supplied to authentication process 10 
authentication process, the invention may issue a digital via application server 130, in a standard application format, 
certificate to the user's machine to record authentication io by client 110. In one aspect of the invention, application 
information, to present for later transactions or to update. An server 130 may be operated by an online vendor, such as a 
illustration of the overall architecture of the invention is in brokerage firm, merchandise retailer or other (see e.g. FIG. 
FIG. 45, and flowcharts of the overall processing flow are 45) and serves as a conduit between client 110 and authen- 
shown in FIGS. 1 and 2. tication server 120 once authentication process 10 is 

In terms of the network environment of the invention, in 15 invoked. It is possible however for client U0 and authen- 

an embodiment illustrated in FIG. 12, client 110 communi- tication server 120 to communicate the requested data 

cates with application server 130 over a physical or wireless directly without passing through application server 130. 

transmission link 150. Transmission link 150 may be a'direct *■ The user inputs the first type of information requested into 

Internet connection or include the Internet as an intermediate client 110. Data may be queried from the user through 

segment. Transmission link 150 may include a dial-up 20 textual questions, graphical user interfaces (GUIs), hyper 

Internet connection, dial-in server access, an intranet text markup (HTML) forms or any other suitable 

connection, a IT or T3 digital line, an ISDN digital line, mechanisms, either in a real-time interactive environment or 

LAN connection, a wide area network, Ethernet, DSL con- through a batch submission. Selection of the input mode 

nection or other wired or wireless connection. may depend upon various factors such as resource loading 

In an Internet context, application server 130 preferably 25 and availability, business model, user and system traffic and 

contains Internet server software (such as the publicly transaction criticality. 

available Apache package or others) communicating with a Following the initialization of the transaction record 112, 

browser application resident on client 110, which may be a the association check 24 may be executed. Before entering 

personal computer or workstation running the Microsoft the preprocessing step 26, the authentication process 10 may 

Windows™95 or 98 operating systems, Internet access 30 invoke association check 24 to evaluate whether the request 

device such as a WebTV™ unit, or other hardware or under consideration is associated with other requests or 

software. attempts, whether recent, concurrent or otherwise. The pur- 

The system includes an authentication server 120 on pose of the association checks is to filter requests suspected 

which the authentication process 10 of the invention is 35 to be fraudulent or part of an attack of some kind. Pattern 

resident and executes. Authentication process 10 may be for recognition (illustrated in FIGS. 17 and 18) may be used to 

instance implemented in programmed machine instructions, identify requests which should be identified as having a fatal 

such as in C, C++, Java or other compiled, interpreted or defect or potential for fraud, requiring immediate rejection 

other computer programming languages. In an alternative of the request. 

embodiment, authentication process 10 may, be, .coresident ^ In a preferred embodiment, authentication process 10 

on application server 130, obviating the need for authenti- stores information received through all requests in the 

cation server 120. Authentication server 120 and application authorization database 152, which stores transaction record 

server 130 each may each be a workstation or personal 112 logging all input received from the user. Using this 

computer, for instance running the Unix, Linux or Microsoft information, association checks based upon available data 

Windows™ NT™ operating systems or other hardware and 4S are facilitated. For example, if one attempt at access includes 

software, and each may communicate with various data- a name and an associated social security number, a concur- 

bases to obtain user identification information for first and rent or later request with the same name but a different social 

second level authentication, security number may be denied or flagged for further 

As illustrated in FIG. 12, such databases may include a authentication, 

credit database 160, mail database 170, phone database 180 50 Conversely, if the later request includes a different name 

and one or more other databases 190 which may be directly but the previously submitted social security number, the 

or indirectly accessible by or resident on authentication request may also be denied or flagged for further authenti- 

server 120 or application server 130. In addition, authori- cation. Association checks can examine any data provided 

zation database 152 is associated and communicates with by the user before or during the preprocessing step 26. 
^authentication server 120. Aumentication pro^ss'lO^ref^^f ' Aftcr'associatibn check; 24; thepreprocessmgstep26 

erably receives and stores data to and from the authorization execute at one or more of authentication client 110, authen- 

database 152, including transaction record 112 (illustrated in tication server 120 and application server 130. Preprocess- 

FIGS. 13-16) which logs user input, queries and other mg step 26 at client 110 may be effected through the use of, 

information as a temporary or permanent record. for example, the transmission of Java applets to client 110 or 

FIG. 12 also shows one or more resources 140 which are eo through other software resident or executing on client 110. 

accessible to application server 130. These may include, for Thus, although authentication process 10 is shown in FIG. 

example, databases, other computers, electronic memory, 12 to be resident on authentication server 120, portions or all 

CD ROMs, RAID storage, tape or other archival storage, of authentication process 10 may be distributed elsewhere, 

routers, terminals, and other peripherals and resources. One advantage of the preprocessing step 26 is that it 

According to the invention, a user who wants to access 65 processes as much of the requested data as possible before 

information or process a transaction over a network is retrieving data from separately stored data sources such as 

prompted to submit information to authentication process 10 credit files, which can be expensive in terms of processing 
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resources, time and cost. Those separate data files may be 
accessible via the Internet or other networks, may be owned 
by separate entities and may involve a per-access charge. 
The preprocessing step 26 involves in one regard assuring 
that data formatting is consistent between the information 
supplied by the user and what is expected in the databases. 

Preprocessing step 26 thus helps to ensure that the sup- 
plied data is as accurate as possible to increase the likelihood 
of generating a match when the user's identity is genuine. 
This reduces false negatives due to inconsistencies such as 
supplied nicknames instead of a full first name, contractions, 
missing titles, or mismatched formatting of social security 
numbers applied against known data sources. 

If the data supplied by the user is determined to be not 
feasible, incorrect, or otherwise clearly deficient before 
soliciting data from the separate data sources, it is still 
possible to proceed to those other data sources after the user 
input has been revised to meet the minimum requirements 
without interrupting the overall transaction. 

If the user does not respond to a request for a mandatory 
item of information (e.g., name) it is preferable to reprompt 
the user for that field before incurring any database charges 
or expending additional processing resources. Another 
example where interception in this manner is beneficial is 25 
when a user supplies a six digit social security number. In 
this case it is clear that the response is deficient and no match 
is possible in the social security number databases, so those 
databases should not be unnecessarily accessed. 

In a preferred embodiment, the preprocessing step 26 may 
perform one or more of the following validation checks. 

1) Standard Field Checks. To ascertain whether all 
required information fields are present and in the proper 
format and if not, reprompt for them or reformat them 
as necessary to proper form. 

2) Social Security Check. The input social security num- 
ber is compared with one or more published social 
security number tables or processed using one or more 
algorithms to determine its validity.vThese tables may 
include such information as numbers reported as 
deceased or fraudulent. 

3) Address and Telephone Checks. The address and tele- 
phone number provided are verified for consistency 
(i.e., city, state, and zip code agree; area code agrees 
with state) and the user's address is standardized. 
Standardization allows for more accurate matching 
with other databases at later stages of authentication 
process 10. During the preprocessing step 26, rejection 
or flagging for additional authentication may occur as 
a result of mismatches. 

4) Driver's License Validation Check. The input driver's 
license number is processed to verify that the number 

v _ _ is, valid for the state of. issue. These algorithn^ may be w . 
obtained through departments of motor vehicles or 55 
otherwise. 

The following information is preferably prompted for (R 
being required, O being optional) by authentication process 
10 during preprocessing step 26 and supplied by the user: 

60 

TABLE 1 



TABLE 1 -continued 



40 



50 



DESCRIPTION 



REQ/OPT 



Suffix 

Maiden Name, if applicable 
Current Address (CA) 
At CA <2 Years Indicator (Y/N) 
Former Address 



Home Phone Number 

Area Code Change Indicator (Y/N) 

Home Phone Published Indicator (Y/N) 

Work Phone Number 

Gender 

Date of Birth 

Social Security Number 

Drivers License Indicator (Y/N) 

Drivers License Number (DL) 

Drivers License State of Issue 

Mother's Maiden Name 
Year of High School Graduation 
Number of Siblings 
Email Address 



0 
0 
R 
R 

Ronly if AtCA<2 Years 

Indicator is Y, otherwise 

Optional 

R 

R 

R 

0 

R 

R 

R 

R 

R only if DL Indicator set to Y f 

otherwise Optional 

R only if DL Indicator set to Y, 

otherwise Optional 

0 

0 

0, includes half and step siblings 
0 



Other, non-wallet information, which is used for subse- 
quent levels of authentication, can be collected during 
preprocessing step 26 or deferred until a later phase of the 
authentication process 10. A user failing to supply this 
information during preprocessing step 26 may be 
reprompted for it, and processing may or may not continue 
in the event the user never supplies information designated 
as required. This information preferably includes: 



TABLE 2 



35 



DESCRIPTION 



REQ/OPT 



Name of Lender 
Loan Account Number 
Loan Type Indicator 
Monthly Payment Amount 



R, only if Second Level Authentication used 
0 

R, only if Second Level Authentication used 
R, only if Second Level Authentication used 



DESCRIPTION 



REQ/OPT 



Last Name 
First Name 
Middle Initial 



65 



Preprocessing step 26 may thus include a set of validation 
checks including standard field checks, social security num- 
ber validation, address validation, area code validation, and 
driver's license validation and other preliminary data veri- 
fication. It is preferable that preprocessing occur in the order 
presented, in part due to data dependencies of later checks 
on the earlier ones. However, it will be understood that the 
order may be rearranged, and different preprocessing checks 
may be employed. The enumerated validation checks are 
discussed in more detail in order below. 

First, standard field checks preferably occur at client U0, 
where and when the requested data is collected, to ensure 
that all required data is present and all provided data is in the 
proper format and meets mmimurn requirements. Complet- 
ing this processing at client 110 minimizes the number of 
requests that must be terminated at this early point in the 
authentication process due to formally incorrect data. This is 
particularly important when the user is not present at the 
time of authentication, such as when requests are submitted 
in batch form rather than interactively. In general, the 
standard field checks make sure that an expected range or 
format of characters are input by the user, appropriate to 
individual queries and data types. 

The following is preferably accomplished during standard 
field checks: 

1) All required fields must be present. 
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2) All provided fields must be in the proper format. 
First name must have at least one letter provided. 
Phone numbers must have 10 digits. 
Social security number must have 9 digits. 
Social security number must not have all 9 digits the 5 

same. 

Social security number's first 3 digits must not be equal 
to 000. 

Social security number's 4 rt and 5 th digits must not be 
equal to 00. 1Q 

Social security number's last 4 digits must not be equal 
to 0000. 

3) Specified fields must meet additional requirements. 
Age, derived from date of birth, must be 18 years old 

or older (However, a telephone number and drivers 
license may still be verified, even if a credit file is not 15 
available). 

Email address must contain an @ sign and a ".com" or 
other domain. 

The user is preferably afforded up to two additional 
attempts to correct any fields that do not meet the standard 20 
field check requirements. If any field cannot be corrected 
after a total of three attempts, the authentication process 10 
is preferably aborted. If the request has been successfully 
completed as determined by the standard field check portion 
of preprocessing step 26, the request may continue to the 25 
next preprocessing check. 

At that next stage of standard field checks, the social 
security number may be checked for some or all of the 
following: 

Social security number contains 9 digits 30 
Social security number *4H)0000000, 11111111, . . . , 

999999999. 
Social security number first 3 digits *000 
Social security number 4th and 5th digits *00 35 
Social security number last 4 digits *0000 
Social security number does not match any social security 

number found on the Social security number fraud 

table. 

Social security number is in the issued range as deter- 40 
mined by a lookup on the social security number range 
table. 

Date of birth agrees with the social security number issue 
dates. 

The check against the published social security number 45 
fraud table is used to ensure that the supplied social security 
number is not listed as fraudulent. Such a table may be 
obtained from any of a number of sources including, for 
example, credit reporting companies or law enforcement 
agencies. The social security number range table is used to 50 
ensure that the supplied social security number is not an 
invalid number. Such a table may be obtained from any of 
a number of sources including, for example, governmental 
agencies. 

Once it has been determined that the social security 
number has been issued, and a range of issue dates is known, 
the date of birth provided on the request can be compared to 
the date range for consistency. It is thus possible to perform 
another check to ensure that the social security number is 
valid based upon date of birth information. 

The user is preferably given only one additional attempt 
to correct social security number information that has been 
rejected by social security number validation checking. If 
the social security number cannot be accepted after a total of 
two tries, authentication process 10 is preferably aborted. 

Next, the validity of address information is confirmed, 
preferably using an address correction and standardization 
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package (such as the PostalSoft package available from First 
Logic Corp.). For current address, and former address if 
provided, the package may: 

Verify that the city, state and zip code agree. If only a city 
and state are provided, the package may be able to add 
the zip code. If only a zip code is provided, the package 
usually can add the city and state. 
Standardize the address line. The package can correct 
misspelled street names, fill in missing information and 
strip out unnecessary punctuation marks and spaces. 
Identify undeliverable addresses (i.e., vacant lots, con- 
demned buildings, etc.). 
Create a status code that tells how an input address had to 
be corrected. 

Create an error code that tells why an input address could 
not be matched, or assigned. 
* - Responses, or actions, for each of the possible address- 
related status codes or error codes in error code matrix 156 
(illustrated in FIGS. 9-11) are provided as output during the 
preprocessing step 26. The user is preferably given only one 
additional attempt to correct each address that has been 
rejected by address validation. If the address cannot be 
corrected after a total of two attempts, the request proceeds 
as designated in the response matrix 154 illustrated in FIGS. 
9-11. The response matrix 154 may be located on authen- 
tication server 120, in authorization database 152 or else- 
where and serve to associate messages with test results and 
transaction records during the address portion of preprocess- 
ing step 26, concurrently with overall application process- 
ing. 

In other words, the response matrix 154 sends messages 
to client 110 based upon specific verification tests or based 
upon the current status of the transaction record 112. For 
example, the message may prompt the user to verify that 
data which was input is correct or a message to direct the 
user to call customer service for manual intervention. The 
response matrix 154 is preferably parameter driven, so that 
appropriate messages can be associated with particular 
events. 

The area code for the home phone number is preferably 
checked to determine if it is valid for the state supplied in the 
current address, in preprocessing step 26. The area code and 
state provided in connection with the request are compared 
with an entry for the area code in an area code table, 
available from database and other sources. The area code 
table contains area code information for each of the area 
code locations in the geographic area being served. 

The database for the area code and associated information 
may be preferably implemented, for example, using the 
commercially available MetroNet package. The phone num- 
ber database information may be stored in phone database 
180 connected to authentication server 120, or otherwise. 
The consistency. of area code to state of residence may, for 
55' 'instanceVbe , checked. 

The user is preferably given only one additional attempt 
to correct home phone number information that has been 
rejected by the area code validation check. After the home 
phone number has been accepted or after a total of two tries, 
60 the process indicates the result, valid or not valid, in the 
transaction record 112 and proceeds. 

Next, the drivers license number is checked to ensure that 
the format of the number is consistent with the format for the 
state of issue. An algorithm may look up the state of issue 
65 and compare the driver's license number provided in the 
request with the accepted format for the state. The user is 
preferably given only one additional attempt to correct 
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driver's license number information that has been rejected 
by the driver's license check (or may be terminated 
immediately, according to vendor preference). After the 
driver's license number has been accepted or after a total of 
two tries, the authentication process 10 indicates the result, 5 
valid or not valid, in the transaction record 112 and proceeds. 

In the event the user will be paying for a product or 
service with a credit card, authentication process 10 may 
invoke credit card verification at this point In this case, 
checks may be executed against a credit card database. 10 
These checks may include ensuring that the available credit 
line is sufficient to make the purchase, ensuring that the 
billing address for the credit card in the database matches the 
submitted address, and ensuring that the credit card is not 
stolen. Databases presenting this sort of information are 15 
commercially available. 

Preprocessing step 26 thus may include internal correc- 
tions as -well as comparisons of user-supplied data to known 
data which may be obtained from separate sources. Those 
sources may be third party databases such as commercial or 20 
government databases, or internal databases. Preferably, 
however, preprocessing step 26 is limited to checking user- 
supplied data against wallet-type data which is relatively 
conveniently, and locally, accessed. Preprocessing step 26 
consequendy offers increased certainty of authentication by 25 
using additional databases and requiring internal consis- 
tency as a predicate to first and second level authentication. 

In conjunction with the checks carried out by preprocess- 
ing step 26, credit database 160 may be any suitable con- 
sumer credit history database available from various sources 30 
including credit reporting companies such as Equifax™. 
Mail database 170 and phone database 180 may be any 
suitable databases providing address and telephone infor- 
mation for the relevant geographic area (e.g., MetroMail 
which is a compendium of regional Bell operating company- 35 
supplied information). Other databases 190 may include, for 
example, a check services drivers license database which 
provides information concerning check validity. Any com- 
mercially available or internal database or others may be 
-employed in processing the verification substeps of the 40 
preprocessing step 26. 

Additionally, the checks of preprocessing step 26 may 
include the use of a credit card application fraud model, or 
some other model which statistically analyzes response data. 
For example, the data supplied by the user may be modeled 45 
and graded for confidence level based upon empirical mod- 
els supplied by third party vendors or available internally. 
An illustration of pattern recognition criteria that may be 
employed in this regard by the invention is illustrated in 
FIGS. 17 and 18. As illustrated in those figures, in general 50 
the invention monitors user input recorded in transaction 
record 112 or otherwise for repetitive attempts at 
authentication, which may represent attempted fraud or 
some type of network attack . . 

"" In such instances, and as' illustrated in pattern recognition 55 
criteria matrix 904 shown in FIG. 17, the input may include 
valid portions of information such as a social security 
number but varying unsuccessful attempts to find valid input 
for other fields. At any time during authentication process 
10, the invention may preempt the authentication event and 60 
terminate the session when pattern recognition senses a 
significant probability of irregularity. Different responses to 
different types of detected potential fraudulent transactions 
are shown in the pattern recognition match action matrix 912 
of FIG. 19. As illustrated in the figure, different types of 65 
inconsistencies may result in different actions, including the 
locking out of suspected fraudulent entries for such patterns 
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as the same name under varying email addresses. Other 
inconsistencies may result in the starting of the authentica- 
tion process 10 over again (QILT entries) at user request. 

In a preferred embodiment of the invention, the data 
supplied by the user must match a record from at least two 
data sources to graduate from the preprocessing step 26. 
This increases the level of certainty that the user's identity 
is genuine before graduating from that stage. Matching 
routines, implemented for each data source and type of 
check, compare query data to known source data and pref- 
erably assign a value to every match instance. This value 
may be termed an authenticity certainty score. An authen- 
ticity certainty score may be accumulated based upon the 
collective values assigned for each match instance of pre- 
processing step 26. Hie authenticity certainty score may be 
employed and compared against predetermined thresholds 
to determine the next action for the request (i.c., approve, 
approve with restrictions, deny, go-^to first or other level 
preprocessing). 

If the data provided by the user does not meet the 
requirements of some or all of the checks of preprocessing 
step 26, a message may be returned to the user via link 150 
requesting the data in question be corrected and resubmitted. 
Upon resubmission, the input data will again be analyzed. 
Alternatively, authentication process 10 may be preconfig- 
ured to immediately reject a request based upon a failure to 
satisfy a minimum level during preprocessing step 26. 

If the request is identified as a result of the association 
check 24 or other analysis as possibly fraudulent using the 
association check or otherwise, a message may be returned 
to client 110 indicating that the request cannot be processed 
automatically and that manual processing such as calling 
customer service is necessary. 

Biometric data may be employed either alone or in 
combination with the above preprocessing as well as sub- 
sequent authentication levels to ensure the identity of a user. 
That biometric data may include, for example, fingerprint 
information from the user, captured in analog or digital 
form, for instance, via an imprint peripheral connected to 
client 110. Biometricdatamay also include infrared or other 
retinal or iris scans, or finger or hand geometry matches. 
Likewise, biometric data used by the invention may also 
include handwriting recognition, voice recognition using 
digitized sampling or other means or facial recognition input 
from video or other devices. 

The biometric data may also include DNA database 
matching. In general, any biometric technology now existing 
or developed in the future may be incorporated in the 
invention. The biometric data may be used as input fields or 
records in the preprocessing, first or second authentication 
level stages. Alternatively, biometric data may be used as a 
key to unlock and release a digital certificate 902 issued to 
the user, to be stored on client 110 or otherwise. 

FIG. 1 is a flowchart Ulustrating.the overall authentication, 
process' according to the' invention." Authentication process 
10 starts at step 12. The authentication process 10 prompts 
a user for first level information at step 14. Again, the first 
type of information is preferably wallet-type information, 
that is, information such as name, address, driver's license 
or other information commonly carried on the person. The 
user inputs that first level information via a keyboard, 
mouse, voice digitizer or other suitable input mechanism at 
step 16. Step 18 identifies that the user has completed first 
level information input. Step 20 transmits the input. The 
transaction record 112 is initialized at step 22. 

Step 24 performs an association check on the information 
input by the user. Authentication process 10 may then invoke 
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the preprocessing step 26 discussed above. If preprocessing The transaction record 112 (illustrated in FIGS. 13-16) 

step 26 is included, step 28 may also be provided, which initialized in step 22 is used throughout the authentication 

determines whether preprocessing step 26 is complete. If process 10 to keep track of user input and authentication 

preprocessing step 26 is not complete, authentication pro- results. After the appropriate queries have been processed 

cess 10 may return to step 14 to prompt the user for omitted, 5 and all results stored in the transaction record 112, the 

corrected or additional information, return to step 16 to transaction record 112 is used to determine an authentication 

allow the user to input information, or end authentication score with respect to the request. Step 56 calculates the total 

process at step 30. If preprocessing step 26 is complete, authentication score, and optionally, a score for each data 

authentication process 10 proceeds to step 32 of first level source, data field, etc. The results are categorized as a big hit 

authentication. 10 (B), a regular hit (R), a possible hit (P), or no hit (N) 

Authentication process 10 matches, at step 32, the first depending on results. Those results may then be combined 

type of information input by the user with informatioo with the results of second level authentication process 40 to 

received from one or more separate data sources. Based on determine an overall authenticity certainty score, as illus- 

that comparison, authentication process 10 determines trated in FIGS. 23-28 and discussed below, 

whether the first level authentication is complete at step 34. 15 Authentication process 10 determines whether one or 

If the first level authentication is not complete, authentica- more of the authentication scores is greater than or equal to 

tion process 10 may return to step 14 to prompt the user for a predetermined authentication value or threshold at step 58. 

vomitted; -corrected or additional information, return to step If the authentication scores-are greater than or equal to the 

16 to allow the user to input information, or end authenti- predetermined authentication value, authentication process 

cation process at step 36. 20 10 renders an authentication decision at step 60 and then 

If the first level authentication is complete, authentication ends at step 62. 
process 10 determines at step 38 whether the user should be If one or more of the scores are less than their corre- 
authenticated. If the user has not been rejected outright but sponding predetermined authentication value, authentication 
has not yet been authenticated, authentication process 10 process 10 determines whether the level of certainty meets 
proceeds to step 40, second level authentication. Step 40 25 a predetermined certainty level at step 64. If the level of 
request and tests the user's input of a second type of certainty is below the predetermined certainty level, authen- 
information, which is preferably non-wallet type informa- tication process 10 ends at step 66. Otherwise, authentica- 
tion, tion process 10 determines whether corrected or additional 

Authentication process 10 determines whether a request first type information is needed at step 68. If no other 

for information has been repeated more than a predeter- 30 information is needed, authentication proceeds to step 40, 

mined number of times at step 42. If the attempt exceeds the second level authentication. If user input information needs 

predetermined limit, authentication process 10 ends at step to be revised, authentication process 10 may return to step 

44. If the attempt does not exceed the predetermined limit, 14 or step 16. 

authentication process 10 determines whether step 40 is FIGS. 31-33 illustrate a set of queries associated with 

complete at step 46. If step 40 is complete, authentication 35 preprocessing step 26 and first level authentication 32 in an 

process 10 renders an authentication decision at step 48, then example authentication session according to the invention, 

ends at step 50. If step 40 is not complete, authentication As can be seen in the figures, these phases of the invention 

process may return to step 38 or end at step 47. query for and process wallet-type information to reach a first 

FIG. 2 is a flowchart illustrating the process of the first level of confidence about the genuineness of the user's 

slevel authentication step 32 in more detail. First level 40 identity. - * *>:.v>.«a*.'-- 

authentication process 32 initiates at first level comparing FIG. 3 is a flowchart illustrating the second level authen- 

step 52. The first level comparing step 52 compares the tication process 40 in more detail. Second level authentica- 

information input by the user with information about the tion process 40 begins with step 310. Step 310 accesses 

user retrieved from one or more known data sources. The available second type information from data sources, such as 

user may be queried in the first level authentication step 32 45 a credit file. Step 312 prompts the user for second type 

for similar information to that accepted during the pre pro- information from within that determined to be available in 

cessing step 26, or for refined or additional information. step 310. Step 314 determines whether the user input 

During processing of any user-input phone number in for- matches the accessed information. 

ma tion in the first level authentication step 32 after pre pro- In the execution of second level authentication process 

cessing step 26 (but preferably not in preprocessing step 26 50 40, authentication server 120 may access credit database 

itself), if the user indicates that they have been at the home 160. Credit database 160 may be preferably implemented, 

telephone number for less than four months, the home for example, using a commercially available Equifax™ 

telephone number and related source information may be consumer credit file, in the ACRO file format, 

preferably further checked against an electronic directory Inquiries may be trarismitted,.back and forth ..between 

' assistance source, for better currency as compared to an 55 application server 130 arid authentication server 120 during 

online database. During processing of any user-input driv- second level authentication process, using the System-to- 

er's license information in the first level authentication step System 93 (STS) inquiry format for these types of data files, 

32 (but preferably not in preprocessing step 26), any further as will be appreciated by persons skilled in the art. Credit 

checks against the driver's license database may be prefer- line information returned from credit database 160 may be 

ably implemented, for example, using the commercially 60 in System-to-System file fixed format (FFF), consistent with 

available ChoicePoint drivers license database. Information the ACRO file configuration. Second level authentication 

from that external database is generally derived from official process 40 executes the search against credit database 160 to 

department of motor vehicle records or insurance claims match the user's input against data in that file, 

information, the content of which may vary by state of issue. The search maybe carried out according to the ACRO L90 

Step 54 assigns values and priorities to each response input 65 search format, with results again categorized as a big hit (B), 

by the user. Information that is of greater significance may a regular hit (R), a possible hit (P), or no hit (N) depending 

be assigned a higher value or priority. on results, which in one embodiment are returned to authen- 
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lication server 120 starting in ACRO header segment posi- may issue a digital certificate 902 to the user, as illustrated 

tion 285 in a 13 byte segment. Matches or no matches are . in FIGS. 37-41. As illustrated in FIGS. 37-40, after an 

returned as logical flags within that header segment. indication of successful authentication the user is directed to 

If the information matches, authentication process 10 input identification and challenge or password information 

either provides a higher degree authentication in step 316 or 5 to generate and store digital certificate 902, The digital 

issues another degree of authentication in step 318. If the certificate 902 contains a set of fields including user 

information does not match, authentication process 10 may identification, a digital certificate serial number, an expira- 

issue a lower degree authentication, return to step 312 or end tion period, as well as information related to the issuer of the 

at step 324. digital certificate and fingerprint data for the digital certifi- 

An example of point scoring used in second level authen- 1Q cate. 

tication according to the invention is illustrated in FIGS. 20 The digital certificate 902 may be preferably stored in 

and 21. The scoring matrix 906 of FIG. 20 includes a set of secure fashion on client 110, that is, protected by user 

point values for point values related to trade line accounts identification and challenge or password queries before the 

which the user may have, on a sliding scale according to the recipient can release the digital certificate 902 for further 

relative degree of significance of various accounts. In transactions, as illustrated in FIGS. 37 and 38. Digital 

general, and as indicated in the relative weight matrix of 1S certificate 902 may be a data file stored in common machine 

FIG. 21, the proper identification of a lender name is given readable format that upon proper release by the user can be 

greater weight compared to monthly payment amount or presented to other authentication servers for later 
terms of account data?*" * CMt - transactions, as evidence of identity and avoiding' the need u 

In FIG. 22, the resulting certainty scores are ranked to reauthenticate the user for later events. As illustrated, 

according to four categories of big hit (B), regular hit (R), 20 digital certificate 902 contains an expiration field, but the 

probable hit (P), and no hit (N). Different combinations of certificate can be generated to persist indefinitely, 

accounts may lead to different maximum scores, according Digital certificate 902 may be updated using a full or 

to the reliability or significance of the accounts available for abbreviated authentication process 10 according to the 

second level authentication step 40. invention, according to the grade of security required for 

Upon completion of both the first level authentication step 25 particular future transactions. For example, a digital certifi- 

32 and second level authentication step 40, results of all cate 902 ma y te issmd recording a medium grade of 

checking may be assembled to determine an overall authen- confidence of the user's identity, but to execute a sensitive 

licity certainty score, values for which are illustrated in the transaction , the user may need to update and upgrade the 

overall certainty scoring matrix 918 of FIGS. 23-28. In ^J*^??*?? ^ l 1 f ter transaction, 

general in those figures, big hits on credit file (second level 30 Almough lUustmed with i two . levels of authentication 

authentication) checks confribute to higher overall certainty 2!£^ that the mvention contem- 

' t . , ^ _ ,*r: TT . 7 plates three or more levels of authentication performing 

scores, which are normalized to 0 to 100 However, prefer- * dditional & ecks using additional databases or prompting 

ably no single check qualifies or disqualifies a user from me ^ for more informatioilj when a pp r0 p riat e £> transac- 

authentication. tion requirements. Any of the levels of the authentication 

Rather, according to the invention the aggregate weight- 35 process 10 may be implemented via an interactive query 

ing of all the user's response is factored into a variety of format, e.g., using a multiple choice check-off box. At no 

possible score ranges, depending on how highly the infor- time during presentation of the interactive query is the user 

mation they supplied correlates to the entire collection of presented with potential answers revealing only correct 

data sources used by the invention. The scoring levels may information, so that identification information cannot be 

be aggregated as - shown in the assignment matrix 920 of 40 captured simply by entering authentication^process 10. 

FIG. 29 to develop a tiered categorization (B, R, P, N) for all Moreover, in the implementation of the invention it is 

levels of authentication, and generate responses according to possible to follow the entire authentication process 10 with 

threshold table 922 as illustrated in FIG. 30. While particular a consumer profiling step, in which the now-authenticated 

numerical levels are shown in those matrices, it will be user identity is associated with purchase, travel, geographic 

appreciated that the different scores and tiers are selectable 45 and other information to enable more highly targeted mar- 

or scalable according to application needs, in the invention. keting or transaction activity. 

FIGS. 34-36 illustrate a set of queries in screen shot form In general, in the execution of the authentication process 

associated with second level authentication step 40 in an 10 of the invention, answers to the interactive query ques- 

example authentication session according to the invention. tions are given highest relative weighting, followed by 

In general, at this stage the authentication process 10 iden- 50 authentication checks against a user's credit file, followed 

titles and accesses trade (credit) line information to query for by telephone information and then driver's license informa- 

data of a specific and private nature, which enhances the tion. 

security profile of the user. In the example shown, both As shown in FIG. 4 and described above, the preprocess- 

credit and merchant or trade line accounts are queried for ing step 26 may be conducted before the hierarchy of. 

lender identity arid amounts. Accurate identification results 55 authentication levels and' include several preliminary 

in authentication, followed by issuance of a digital certifi- procedures, mainly designed to ensure consistency in for- 

cate 902 as desired. mat. Discussion will return to preprocessing step 26 to 

The system and method of the invention are customizable describe the preprocessing stage in more detail in conjunc- 
to allow a vendor operating an authenticating server 120 to tion with FIGS. 5-8. It will be understood that various 
set various parameters, including the thresholds or prede- 60 combinations of standardization 400, formatting verification 
termined levels at different points of authentication process 410, verifying consistency 420, and verifying data validity 
10. If the predetermined authentication or certainty level has 430 may be incorporated into the preprocessing step 26. As 
not been reached for a particular data source or data field, the illustrated in FIG. 1, after preprocessing step 26 is executed 
user may not be eligible for authentication, or a higher a decision 28 is made whether authentication should pro- 
degree of authentication. 65 ceed. The decision 28 may result in a return to initial step 14 

If a user successfully completes preprocessing, first and or an end to the automated authentication process 10 at step 

second authentication, in one embodiment the invention 30. 
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If preprocessing step 26 includes a formatting verification 
410, the following process may be followed- The user input 
data is checked at step 500 to determine that it is properly 
formatted. For example, the data may be checked to verify 
that the required fields have been entered (e.g., user name) 
or that the proper number of characters have been entered 
(e.g., nine digits for a social security number). If the result 
of the decision 500 is that the data is not in the proper form, 
a determination is made at step 510 whether the user has 
been prompted for this information previously. 

The authentication process 10 may be configured to allow 
a predetermined number of chances for the user to input data 
in the correct format. If the number of attempts exceeds the 
predetermined number, the process may terminate at step 
520. If the predetermined number of chances has not been 
exceeded, the user may be prompted to input the data in the 
correct format at step 530. If the data is in the correct format, 
the process proceeds to step 540. 

FIG. 6 depicts the process for standardization 400'of-the 
data. At step 600 a determination is made whether the data 
is in the proper standard form. For example, the user's postal 
address may be checked for misspelled street names, or 
unnecessary punctuation. If the determination 600 finds the 
data to be non-standard, a determination 610 is made 
whether the non-standard data can be corrected. If the data 
can be corrected, it may be accomplished at step 620 by 
internal or other processes. If the data cannot be corrected, 
a determination is made at step 630 whether the user has 
been prompted for this information previously. 

The authentication process may be configured to allow a 
predetermined number of chances for the user to input data 
in the correct format. If the number of attempts exceeds the 
predetermined number, the process may terminate at step 
640. If the predetermined number of chances has not been 
exceeded, the user may be prompted to input standard data 
at step 650. If the data is in standard form, the process 
proceeds to the step 660. 

FIG. 7 depicts the process for determining the validity 430 
of the data. For example, the validity may be verified by 
determining at step 700 whether the data is valid (e.g., does 
the social security number match any social security number 
found on the published deceased or fraudulent table). If the 
determination is made that the data is invalid, a determina- 
tion 710 is made at step 710 whether the user has been 
prompted for this information previously. If the number of 
attempts exceeds the predetermined number, the process 
may update the transaction record at step 720 to reflect the 
presence of the invalid data. 

After the transaction record 112 is updated in step 720, an 
additional determination is made at step 730 of whether the 
process can proceed with this invalid data. If not, the process 
may terminate at step 740. If it can, the process may proceed 
to step 750. If the predetermined number of chances has not 
been exceeded, the user may be prompted to input valid data 
at step 760. If the data is valid, the process proceeds to step 
750. " 

A similar process may be followed to determine whether 
the data is consistent at step 420, as illustrated in FIG. 8. In 
step 760, the determination is made whether the data from 
separate field entries are consistent. For example, data may 
be checked to verify that the area code entered matches the 
zip code entered. If the determination is made that the data 
entered by the user is not consistent, a determination is made 
at step 770 whether the user has been prompted for this 
information previously. If the number of attempts exceeds 
the predetermined number, the process may update the 
transaction record 112 in step 780 to reflect the presence of 
the inconsistent data. 
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After the transaction record 112 is updated 780, an 
additional determination is made at step 790 of whether the 
process can proceed with this inconsistent data. If not, the 
process may terminate at step 800. If it can, the process may 

5 proceed to step 810. If the predetermined number of chances 
has not been exceeded, the user may be prompted to input 
valid data at step 820. If the data is valid, the process 
proceeds to step 810 and the next preprocessing check. 
FIGS. 9-11 show an example of the use of a matrix to 

10 verify address information in processing validity 430 or 
consistency 420. As shown, the verification process, which 
may be implemented using the commercially available 
PostalSoft, generates a matrix of address values to determine 
certain address information. FIG. 10 shows an example of 

15 certain error codes which may be generated to prompt user 
responses according to PostalSoft format when entered 
values, such as zip code, are not in proper format. FIG. U 
shows an example of certain actions and messages according 
to other types of data entered during processing for consis- 

20 tency 420. 

Generally speaking, there are several ways to administer 
the queries at the various levels of authentication of the 
invention, depending upon the requirements of the transac- 
tion. If the user is available at the time of application for an 

25 interactive dialog (e.g., Internet request), a multiple choice 
questionnaire is preferably dynamically created by authen- 
tication process 10 and presented to the user, through client 
110, for completion. 

Multiple choice alternatives for each question are prefer- 

30 ably selected based upon the regional biases of the user, if 
applicable, and are designed to make it difficult for a 
fraudulent applicant to correctly guess the answers. That is, 
potential selections for various credit line or merchant 
account providers are provided in the same general geo- 

35 graphic region as the user's home address, so that credit line 
account vendors are not obviously wrong based on location. 
The user points and clicks on their selections, or provides 
answers in some other suitable way. The user-supplied 
answers are then returned to authentication process 10 by 

40 client 110 for automated evaluation. 

If the user is not present at the time of application (e.g., 
batch submission), the information required to administer 
validation is provided on the initial application. If the user 
supplies account numbers, second level authentication step 

45 40 will attempt to make the comparisons automatically. 
However, if the comparisons cannot be made automatically 
or the account numbers are not provided, the comparisons 
may be accomplished manually through human intervention. 
The results are returned to second level authentication step 

50 40 for final evaluation. 

FIG. 18 illustrates an example authentication carried out 
according to authentication process 10 of the invention. In 
general, as illustrated in that figure, the user presents name, 
social .security number, date of birth, email and mailing 

55 address information, followed by home telephone number 
and driver's license data. That information is accepted and 
processed through preprocessing step 26 and first level 
authentication step 32, after which it is determined that the 
data are consistent and merit proceeding to second level 

60 authentication step 40. 

In second level authentication step 40, a sequence of 
questions are presented in an interactive query directed to 
mortgage account information, requesting lender and 
amount information followed by other merchant account 

65 information. Following successful authentication, the user is 
asked whether they wish to generate digital certificate 902, 
which is generated recording the successful authentication 
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and protecting the digital certificate 902 by way of identi- If a user fails to supply a social security number, as 

fication and challenge question data. illustrated in FIG. 42 control is passed to remote authenti- 

Any or all of the processing steps described above can be cation object 1006, which may apply the preprocessing step 
invoked selectively or rearranged to constitute a complete 26 and further steps to test inputted user information. If the 

authentication process 10. The requirements of the tr ansae- 5 inputted user information does not reach a predetermined 

lion will determine which processes to combine for partial- threshold, control passes to a failure state 1022. If a suffi- 

lar authentication needs. It is possible to configure several cient authentication score is reached, processing proceeds to 
different implementations as standard offerings. The vendor offline authentication object 1020. Offline authentication 

employing authentication system (vendor) can either use ob i ect 1020 mailability filter 1024 which processes 

these standard offerings, or customize a configuration to 10 ? e user-supphwl input without a social security number to 

their needs. With any implementation, the invention allows ^f™ whether address standardization age-related, 

« ^-u-v* • j * ■ ■ _ • . c address-related, or fraud nags are present. If a sufficient 

flexibly m determining , certainty of authenticity, enter authentication ' mn is reac * d m lability filter 1024> 

mroughprocessco^ control tQ ^ ^ ^ m ^ a ^ 

In the practice of the invention, m the event of temporary idcntificatioQ PIN ^ t^^ted to mc ^ at the cntered 

downtime or other unavailability of any of the data sources 15 address vshlg regular mail Conversely, if mailability filter 

used for comparison, the invention may revert to a backup ia24 ^ not satisfied, a failure state 1028 is reached in which 

source for that particular type of information (which may be n0 material is mailed and processing terminates, 

generally consistent but not as current)^substitute another An embodiment of the remote authentication system 1002 

data source, or take other action. is illustrated in more detail in FIG. 43, in which a social 

FIG. 42 illustrates an offline remote authentication 20 security supply object 1030 tests whether the user is capable 

embodiment of the invention, in which some processing of providing a social security number field. If the user is 

including delivery of a validated ID is conducted using capable of providing a social security number field, control 

ordinary mail. As illustrated in FIG. 42, in this embodiment, proceeds to pass test module 1032, which may perform 

a remote authentication system 1002 controls two process- preprocessing step 26, first level authentication step 32, 

ing objects, a remote authentication object with a social 25 second level authentication step 40 or other processing. If 

security number field 1004, and a remote authentication the user passes those levels of authentication with a suffi- 

object without a social security number field 1006. The cient score, control passes to an earned icon state 1034, 

remote authentication system 1002 invokes the remote providing the user with an online authentication icon, digital 

authentication object 1004 when a user has presented a certificate 902 or other issued verification, 

social security number, in an online application for a credit 30 If the pass test module 1032 is not passed, a fatal error 

or other transaction. The remote authentication object 1004 object 1036 may test for fatal errors in social security, 

may invoke the preprocessing step 26, to process standard address, age-related or other desired data fields. If fatal error 

field checks as in the other embodiments above. In this object 1036 does not detect a fatal error, control passes to a 

embodiment, in part because of the requirements for mail mailability filter 1038 which tests for mailability using zip 

delivery, failure of one or more data fields for address 35 code and state, name, deliverability and other field checks, 

standardization, such as zip code errors, blank fields, foreign after which a mail state 1040 is entered if the user has 

addresses, and undeliverables may result in a failure state successfully established reliable information. After mail 

1018. The failure state 1018 may also be reached when age state 1040 is entered, both the PIN may be mailed via regular 

is less than a predetermined level, or standard social security mail and a user icon issued in earned icon state 1042. 

checks as described above are not met: -Other factors which 40 Conversely, if either the fatal error object 1036 or mailability 

may result in a failure state 1018 include mismatches filter 1038 are not satisfied with the information the user has 

concerning telephone numbers, social security numbers and entered, a failure state 1044 is entered, and processing ends 

fraud victim indicators present in a credit file. without transmitting an ID via mail or an icon being issued. 

If the remote authentication object 1004 determines that As illustrated in FIG. 44, alternatively if the user is not 

the user has achieved a sufficient score during preprocessing 45 capable of supplying a social security number to social 

step 26 and any further processing steps, the pass state 1008 security test object 1030, then control passes to fatal error 

may be reached. Online issuance of a digital certificate 902 object 1046. If no fatal error is detected by fatal error object 

or other authentication may ensue. However, if the remote 1046, control is passed to mailability filter 1048, which tests 

authentication object 1004 determines that the user's score for deliverable mailing information, as above. If mailability 

lies between those designated for a pass state 1008 and a 50 filter 1048 is satisfied, the mail state 1050 is reached in 

failure state 1018, the remote authentication object may offer which a regular PIN identification is mailed via mail to the 

an offline authentication state 1010, in which verification is user, after which an earned icon state 1052 is reached, 

transmitted using regular mail. issuing the user an online icon identification. Conversely, if 

In this condition, offline authentication state 1010 invokes . . either the fatal error object 1046 or mailability filter 1048 are 

mailability filter 1012, which tests for matches on first 55 not satisfied, a failure state 1054 is reached, and processing 

initial, last name, a house number and zip code from at least ends. 

one address database, as well as consistency of age and year The foregoing description of the authentication system 

of birth and a social security number which is either valid or and method of the invention is illustrative, and variations in 

shows no more than a small number of digit transpositions. construction and implementation will occur to persons 

Other criteria may be applied. 60 skilled in the art. For instance, while the invention has been 

If a sufficient score is reached in the mailability filter 1012 generally described as involving a single user supplying 

processing, a mail state 1014 is reached in which the entered authentication information in a single interactive session or 

addressing information is used to transmit a PIN or other alternatively in batch mode, both queries and user input may 

identification information to the user via regular mail. If a be provided at different times using different input modes, 

sufficient score is not reached in the mailability filter 1012, 65 when the transaction allows. This may be the case for 

a failure state 1016 is reached, no verification is sent by mail instance when the transaction involves setting up an online 

and processing terminates. subscription to publications or services. 
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For further example, while the invention has been v) presenting the at least one query to the user for 

described in a client/server environment in which a user response; and 

initiates a transaction using a personal computer or other vi) evaluating the response. 

device over a computer network, the user could initiate the 9. The method of claim 8, wherein the identity of the user 

transaction over other networks. The user for instance could 5 is authenticated based on the level of correspondence deter- 

conduct a transaction using a cellular telephone equipped mined in step (aXiv) and the evaluation made in step (b)(vi). 

with an alphanumeric display which permits the user to 10. The method of claim 1, wherein at least one of step (a) 

keypad data in over the mobile cellular network. an ^ ste P (°) comprises generating an interactive query. 

For yet further example, while the invention has been 11. The method of claim 10, wherein the interactive query 

illustrated in terms of an individual consumer initiating a 10 comprises at least one question having multiple choice 

network transaction, the invention can also verify the iden- answers. 

tity of other entities such as corporations, schools, govern- 12 ^ method of claim 1, further comprising (e) pre- 

ment units and others seeking to transact business over a processing the first type of information supplied by the user, 

network. Those entities can be international in nature. The wherein the first type of information has a plurality of fields, 

scope of the invention is accordingly intended to be limited 15 The method of claim 12, wherein the step (e) of 

only by the following claims. preprocessing comprises at least one of: 

What is claimed is: i) standardizing at least one field of information; 

1. A method of authenticating a user on a network using formatting at least one field of information; 

credit related information, the method comprising: iii) checking internal consistency between at least two 

a) performing a first authentication step based on a first 20 fields of information; and 

type of information by iv) checking the validity of at least one field of informa- 

i) receiving the first type of information from the user, tion. 

wherein the first type of information is identification 14. The method of claim 13, wherein based on the step (e) 

information, and of preprocessing, the method further determines that: 

ii) processing the identification information; i) the user can not be authenticated; 

b) performing at least a second authentication step based ii) the user can be authenticated; 

on a second type of information other than the first type iii) the second authentication step should be performed; or 

of user identification information by iv) manual intervention is required before making an 

i) retrieving the second type of information from a 30 authentication determination. 

credit reporting company's credit database, wherein 15. The method of claim 1, wherein the first type of 
the second type of information is user credit related information comprises wallet-type information and the sec- 
information compiled from a plurality of sources, ond type of information comprises non-wallet type infor- 
and mation. 

ii) querying the user regarding the credit related infor- 35 16. The method of claim 1, wherein the second type of 
mation; and information comprises information pertaining to credit 

c) if steps (a) and (b) authenticate the user, issuing a accounts to which the user is a party. 

digital certificate. 17. The method of claim 16, wherein the second type of 

2. The method of claim 1, wherein step (a) further information comprises mortgage loan information, and the 
comprises: * 40 *euser is requested to identify at least one of: 

iii) retrieving user information from a data source; and a ) mortgage lender information; and 

iv) determining a level of correspondence between the b > mort g a S e loan amo^t information, 
identification information supplied by the user and the . 18 ^ method of claun halh ^ T comprising (f) receiv- 
user information retrieved from the data source. m S blometric m P ut from the US£r - 

3. The method of claim 2, wherein the data source 45 19 ^ method of claim wherein the network corn- 
comprises a credit file of the user. P nses ^ Internet. 

4. The method of claim 1, wherein the step (c) of issuing 20 ^ mcthod of claim farther comprising (g) logging 
further comprises encoding the digital certificate with pass- a transaction record for at least one of the authentication 
word information. steps. 

5. The method of claim 2, further comprising: 50 21 * ^ method of claim 2 ' further comprising (h) execut- 

d) determining, based at least in part on the level of m S a P atte '° recognition process to detect potential irregu- 

correspondencc determined in step (a)(iv), to: ^ " f ™™T T P k ^ , ■« 

\ » jj V i f L \t 22. The method of claim 1, wherein the digital certificate 

l) request additional information from the user; or „ ■ * , j-' <• . . 

— -= — if)""tilDc""otKcr comprises levels correspondmg T to results of the authenuca- 

6. The method of claim 5, wherein the step (d) of 55 ^^Ji rp, , c , . - , . iL ,. . . 

A . c .i u j i i c _f * \ c 23. The method of claim 1, wherein the digital certificate 

determining is further based on a level of certainty of - m • r • *j 

authentication desired. comprises user identification information, issuer idenUfica- 

t Tu. ~.~*u~a «f i — i u • j * j toon information and expiration information. 

7. Ine method ot claim 2, wherein the data source is used t^tl *u j r i • i t ^ l •• * ^ 

to identify the availability of the second type of information m ^ ^ m f ° f claim ^ comprising <k ge- 

for the user erating an interactive query requesting digital certificate 

8. The method of claim 2, wherein step (b) further ^1"?!!° i *. tU ,,x „ • 
comprises- method of claim 1, further comprising (1) storing 

P ' the digital certificate. 

iii) determining an availability of the credit related infor- 2 6. The method of claim 1, further comprising (m) 
mation for the user; 65 performing an online authentication based upon at least one 

iv) formulating at least one query based on the available of the first type of information and the second type of 
credit related information for the user; information. 
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27. The method of claim 26, wherein the step (m) of 37, The system of claim 36, wherein the interactive query 
performing an offline authentication, comprises applying a comprises at least one question having multiple choice 
mailability filter to at least one of the first type of informa- answers. 

tion and the second type of information. 38. The system of claim 28, wherein the processor pre- 

28. A system for authenticating a user on a network, 5 processes the first type of information supplied by the user, 
comprising: wherein the first type of information has a plurality of fields. 

, • t _e * c . , c • c .* 39. The system of claim 38, wherein the preprocessing 

an input interface for receiving a first type of information - _ . nna , F F 6 

r . . £ . . c : v * * comprises at least one of: 

from the user, the first type of information being t r , ,. . ^ . t c . , _ . f 

identification information; standard.zmg at least one field of mformat.on; 

,10 formattmg at least one field of information; 

a credit database from a credit reporting agency; and checking internal. consistency between at least two fields 

a processor connected to the input interface and config- 0 f information; and 

to: checking the validity of at least one field of information, 

perform a first authentication step based on the identi- 40. The system of claim 39, wherein based on the 

fication information by processing the identification 15 preprocessing, the processor determines that: 

information; the user can not be authenticated; 

perform at least a second authentication step based on the user can be authenticated; 

. i^ 001 ^ ^ of information other than the first type tne second authentication,step .should be performed; or 

of information by retrieving the second type of manual intervention is required before making an authen- 

infonnation from the credit database, wherein the 2Q tication determination. 

second type of information is the user credit related 41. The system of claim 28, wherein the first type of 

information compiled from a plurality of sources; information comprises wallet-type information and the sec- 

and ond type of information comprises non-wallet type infor- 

determine whether to issue a digital certificate based on mation. 

the first authentication step and second authentica- 25 42. The system of claim 36, wherein the second type of 

tion step. information comprises information pertaining to credit 

29. The system of claim 28, wherein the first authentica- accounts to which the user is a party. 

tion step performed by the processor further comprises: 43 The system of claim 42, wherein the second type of 

obtaining the identification information from the user; information comprises mortgage loan information, and the 

. . . - - . interactive query comprises a request for the user to identify 

retrieving user information from a data source; 30 at j east one 0 f 

comparing the identification information supplied by the mortgage lender information; and 

user with the user information retrieved &om the data mortgage loan amount information, 

source, ana ^ -Pk e svstem 0 f daim 28, wherein the processor 

determining a level of correspondence between the iden- receives biometric input from the user. 

tification information supplied by the user and the user 45. The system of claim 28, wherein the network corn- 
information retrieved from the data source. prises the Internet. 

30. The system of claim 29, wherein the data source 45. The system of claim 28, wherein the processor logs a 
comprises a credit file of the user. transaction record for at least one of the authentication steps. 

V 10 s y stcm of claim 29, wherein the processor 47, The system oL claim. 29, wherein the processor 

determines, based at least in part on the level of executes a pattern recognition process to detect potential 

correspondence, whether to: irregularities in the information supplied by the user, 

request additional information from the user; 48. The system of claim 28, wherein the digital certificate 

or take other action. comprises levels corresponding to results of the authentica - 

32. The system of claim 31, wherein the determining is 45 non - 

further based on a level of certainty of authentication 49. The system of claim 28, wherein the digital certificate 

desired. comprises user identification information, issuer identifica- 

33. The system of claim 29, wherein the data source is U0D m & expiration information. 

used to identify the availability of the second type of 50. The system of claim 28, wherein the processor gen- 
information for the user. 50 erates an interactive query requesting digital certificate 

34. The system of claim 28, wherein the second authen- information, 

tication step performed by the processor comprises: 51. The system of claim 50 wherein the processor encodes 

determining an availability of the credit related informa- with password information. 

tion for the user; system of claim 28, wherein the processor stores 

formulating at least one query ' based" on the available 55 ™^mof claim 28, wherein the processor per- 

crecht related mformation for the user; forms an offline authentication based 00 at least one of me 

presenting the at least one query to the user for a response; type 0 f information and the second type of information. 

a °d 54. The system of claim 53, wherein the offline authen- 

evaluating the response. 6Q tication comprises applying a mailability filter to the at least 

35. The system of claim 29, wherein the identity of the one of the first type of information and the second type of 
user is authenticated based on the level of correspondence. information. 

36. The system of claim 28, wherein the processor gen- 
erates an interactive query. * * * * * 
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